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DUPLICATE 



METHOD OF CONNECTING A CUENT RUNNING ON A COMPUTING 
DEVICE TO A SERVER RUNNING ON A DIFFERENT COMPUTING 
DEVICE 

BACKGROUND TO THE INVENTION 

1. Field of the Invention 

This invention relates to a method of connecting a client running on a computing 
device to a server running on a different computing device. 

2. Description of the Prior Art 

When a client (Le. a program making a request for a service) \(dshes to connect to a 
server ^.e. the program that can supply the requested service) over a network, it needs to 
uniquely identify the service. The standard approach relies on the use of 'port numbers'. 
In essence, a port number is a logical address: when one program communicates with 
anodier program on a different computer, it specifies the port number of that program 
in each data transmission so that its messages can be properly received by the correct 
program. For instance, HTTP normally uses port number 80: all HTTP messages firom a 
client are uniquely identified by the client specifying port 80. 

This approach requires manual configuration ^.e. the developer of the client program has 
to manually select a port niopaber, with ICANN designating the so-called Vell-known' 
port numbers 0 to 1023; registered ports running firom 1024 to 49151 and private ports 
.ru nning from 49152 to 65535). It also risks clashes between servers ^.e. if two 
developers choose the same port number). Nevertheless, this approach is workable for 
services provided by OS or device manufia.cturers because those port numbers can be 
fixed when a device is manufactured. However, Independent Software Vendors (ESVs) 
caimot reserve these port numbers and so the conventional approach makes it difficult 
for ISVs to create new services since they face die risk of port number allocations being 
duplicated, witii the risk of clashes arisiog. 
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SXJMMARY OF THE PRESENT INVENTION 

In an implementation of the invention, services instaUed on a computing device register 
their pubHshed name, which conforms to a structured naming convention, such as 
reversed domain information, witii a 'service broker' on that device. The service broker 
uses a single well-known port number address. When an external di^nt wants to use a 
service on die connected computing device, it sends a message to die service broker 
using die wdl known port number. The message specifies die name of die desired server 
and requests diat dae service broker inform it of die appropriate connection point (e.g. 
port number) to use. There is no dependency on port numbers or unstructured and 
arbitraty n?r"^<^g conventions. 

Because service names are made unique by using a structured (and preferably standard 
and open) naming convention, e.g. by pre-pending die service nanie witii reversed 
domain information, new connectivity services can be added to devices witiiout having 
to change die existing configuration of die device. Address clashes are avoided as long as 
new services use die service broker and a consistent naming convention. . 

If a service is re^stered widi die name specified by a cUent to die service broker, dien die 
service broker starts die service. The service obtains a connection point by some means 
and informs die service broker of die connection point address (for TCP/IP diis would 
be a port number, odier transport mechanisms (e.g Bluetoodi, serial, USB, IrDA etc) 
wouki have odier addressing mechanisms). The service broker dien informs die external 
dient of die connection point address of die service. The dient dien communicates 
direcdy widi die server, unlike some prior art approaches, where die intermediary stays in 
position. Widi diis mechanism die only statically allocated address is diat of die service 
broker. 

If a service is required more dian once, die server will not be re-started: instead die 
service broker uses cached address information. 
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When services register with the service broker, they may register a version noamber to 
indicate the version of the service that they are providing (and, optionally, other 
information and how they can be started). The external client can request a specific 
version of a named service or it can omit the version, in which case the service broker 
will start the highest version available of the named service. In either case, the service 
broker informs the remote client of the version of tiie service that has been started. This 
allows a remote client to inter-operate with a range of devices and potentially handle 
different versions of services. 

The service broker can serve external clients that are PC*s or other computers connected 
by a local link such as cable, Tnfra-Red or short distance radio (such as Bluetooth) or by a 
remote link such as a network data connection. 

The service broker can provide authentication information such that only authenticated 
ertemal clients can access services. 

The service broker does not require administration, it is extensible and resolves port 
clashing by using names instead of numbers and names can be easily made unique by 
using internet domain information. 

It provides mechanisms for handling and publishing service version numbers and thus 
allows one client to handle a range of devices. 



Appendix 1 describes a detailed implementation of die present invention for Symbian 
OS. 
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Introduction 
Purpose and Scope 

The piitpose of this dooiment is to describe the functionality provided by the Service- 
Broker. 

The Service Broker provides a mechanism for remote clients to start various service 
providers^ on the device and to retrieve the port nximber for these services. It also 
manages connection authentication, between the device and a remote client Remote 
clients are requested to authenticate the connection before starting named services on 
the device. 

Overview Context 

Error! Reference source not found, shows the Service Broker in its architectural 
context The Bearer Abstraction Layer (BAL) running on the remote dient connects to 
the server socket provided by the Service Broker. The remote client is usually a Windows 
PC but it can be any device capable of establishing a TCP/IP connection to the device. 

An application on the remote client requests die service port number from die BAL 
(defined in [3]). The BAL requests this port number from the Service Broker via the 
messaging protocol described in [1], The name of the service is specified by tiie dient to 
tiae BAL and by the BAL to the Service Broker. 

The Service Broker attempts to start the Service Provider (i£ not akeady running) and to 
retrieve its port number. This is achieved via the CHent Server API described in [2]. 
Once the Service Provider has been started, the Service Broker transmits the port 
number to the BAL, which in turn communicates it to the client application. The 
client application can then establish a direct connection to the Service Provider. 
Functionality 

Functionality for die Service Broker is expressed as a set of use cases, which aire triggered 
by tiie external Inter&ces. 



* Socket servers using die TCP/IP protocol suite and communicating via a protocol that 
must have been defined between client and server. 



8 



table. There is one entry for each service containing the foUoTving:- 

- Service Name; 

- Process Name (the name of the process that implements 
this service); 

- Exe Location (full path and file name for the exe file 
implementing the process), 

- Command line arguments (tiie command line arguments to 
be used when starting die process). 

- Service Version (minor, major and build number). 

- Registration file name (the name of the registration file that 
specifies the service name)^. 

Normal j£ starting up scan the ROM registration directory. For every xml file 

Execution How (extension .xml) perform as specified in 0, 

Scan the non-ROM re^tration directory. 

For every xmJ file that has been removed: 

The services belon^g to the file are removed firom the table. 

For every file that has been added or updated:- 

Open the file and parse it 

Store the service into the services table. There can be more than one service 
defined in a registration file. 

Qose the file 

Post-condition The services table is up to date widi die registration directory. 
Exceptions ^ re^stration file cannot be opened, in this case log an error and ignore the 

registration file. 

The syntax of a registration file is wrong, in tiiis case log an error and ignore 



^ This is not specified in the file itself but it is stored in the table because a service 
overwritten later on only if it is in die same registration file. Also, if registration £ 
deleted, die services corresponding to dais file will be removed firom die table. 
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the registration file. 

A registration file specifies a service name, which is already registered. In 
this case, only update the services table if the registration file is the same, 
otherwise log an error and ignore this service. 

A registration file specifies a service name more than once. In this case 
override the previous service information, only keep the one read last. 
However, log an error message. 



Shutdown 



Pre-condition 
Description 

Normal ' 
Execution Flow 



Post-condition 
Exceptions 



The System is running. 

The System is asked to terminate, this is usually done during the device 
shutdown procedure. 

Stop the client server interface disconnecting any active sessions. 
Disconnect all the connected remote clients. Close the server socket 
Terminate execution. 
The system has terminated. 
None. 



Accept Remote Client Connection 



Pre-condition 
Description 

Normal 

Execution Flow 

Post-condition 
Exceptions 



"Startup" has completed successfully. 

Accept a connection firom a remote dient. The maximum number of client 
connections that can be accepted at the same time is defined in [1]. 

Create a new client socket 

Receive messages on the socket 

There is a new client socket 

The client socket cannot be created. In this case the client connection 
request is not accepted and an error is displayed. 

An unrecognised message is received, in this case discard the message and 
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log and ectot.. 



Get Device Infoimation 

Pre-condition "Accept Remote Client Connection" has completed successfully. 



Description 
Notmai 

Execution Flow 



Post-condition 
Exceptions 



A "Get Device Information" message has been received ftom die remote 
client Messages are described in [1]. 
Read the message header. 

Retrieve tiie device information (from interfacing to die HAL). 

Compose "Device Information'' and send it to die client. 

The message ID of the outgoing message must be die same as die one 

received in die incoming message. 

The message has been handled. 

The device information cannot be retrieved for some reason. In diis case, 
compose an error message and send it to die cUent. The error code is 
"Internal Failure"*. 



Get Version 

Pre-condition 

Description 

Normal 

Execution Flow 



Post-condition 
Exceptions 



"Accept Remote Oient Connection" has completed successfuUy. 
A "Get Version" message has been received from die remote dient. 

Read die message header. 

Compose "Device Version" and send it to die client 

The message ID of die outgoing message must be die same as die one 
received in die incoming message. 
The message has been handled. 
None. 



^ Error codes are defined in [1]. 



11 



Authenticate Coimection 

Pre.condition "Accept Remote Oient Connection" has completed successfuUy. The 
conneiction is not authenticated (see 0). 

A "Audienticate Connection" message has been received from the remote 
client. 



Description 
Normal 

Execution Flow 



Post-condition 
Exceptions 



Read the message header and generate a random number. 

Send the random number to the dient in a 'TRandom Value" message. Wait 
for a 'Tassword" message from die client 

When 'Tassword" is received from the client communicate die random 
number to the password provider DLL and retrieve a hash of the password 
and die random number. Compare diis hash widi the one received from die 
remote client in die 'Tassword" command 

If die two hashes are die same dien send a "Connection Audienticated" 
message to die cUent This indicates diat any connection received from the 
client (from die same IP address and on the same physical bearer) should 
be considered audienticated until the physical link is dropped. 

The connection is audienticated. 

If the hash supphed by the dient is not die same as the hash created by die 
password provider DLL send an error message to the cUent, with code 
"Audientication Failed", 

If the hash cannot be retrieved from die password provider DLL, send an 
error message to the client with code "Authentication Failed" and log an 
error message as well. 



Get Services 
Pre-condition 

Description 



"Accept Remote Client Connection" has completed successftiUy, The 
connection is audienticated. 

A "Get Services" message has been received from die remote client. 
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Normal 
Execution Flow 



Post-condition 
Exceptions 



Read tiie message header. 

Retrieve the list of services from the services table (0)- 
Compose "Services" and send it to the client. 

The message ID of the outgoing message must be tiie same as the one 
received in the incoming message. 

The message has been handled 

No services are available. In this case return a "Services" message with an 
empty list 

The connection is not authenticated, in this case return to the client an 
error message with code '"Not Authenticated". 



Get Service Version 

Pre-condition "Accept Remote CUent Connection" has completed successfully. The 



Description 
Normal 

Execution Flow 



Post'Condition 
Exceptions 



connection is authenticated. 

A "Get Service Version" message has been received from die remote dient. 
Read the message header and extract the service name from the message 
data. 

Retrieve die version supported for dds service from the services table (0). 
Compose "Service Version" and send it to die client; 

The message ID of die outgoing message must be the same as die one 
received in the incoming message. 

The message has been handled. 

The specified service is not in die services table. In tiiis case send an error 
message to die client with error code **Not Foxmd". 

The coimection is not authenticated, in this case return to die client an 
error message widi code 'TMotAudienticated". 
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.Start Service 
Pre-condition 

Description 
Normal 

Execution Flow 



Post-condition 



Exceptions 



"Accept Remote Client Connection" has completed successfully. The 
coxmection is authenticated. 

A "Start Service" message has been received from the remote client 

Read the message header and extract the service name. Also extract a 
timeout value as specified in [1]. * 

Checks die process associated witii this service (the Service Provider) is 
already running. Use the information stored in die services table to do tiiis 
(0). 

If the process is not running start the process and a timer using the timeout 
extracted above. 

When die Service Provider registers itself (0), send its port number to die 
client in a "Service Started" message and stop die timer. 

At die expiry of the timer send an error to die client with code "Failed to 
Register^'. 

The message ID of die outgoing message must be the same as the one 
received in the incoming message. 

If the Service Provider is already running dien compose "Service Slafted" 
and send it to die client The port number is stored in die services table. 

The message ID must be the same as the one received in the incoming 
message. 

The message has been handled and the requested Service Provider is 
running. 

The specified service is not in the services table. In diis case send an error- 
message to die dient with code *TSIot Found". 

The process cannot be started. In this case send an error message to the 
client with error code "Cannot Start". 
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When registering itself, tihe process may communicate a failure code instead 
of a port number. This can be done via the API specified in [2]. In this case 
send an error message to the client Mnih error code "Cannot Startf' and with 
extended error code equal to the error received fix>m the process. 
The coimection is not authenticated, -in this case return to the client an 
error message with code **Not Authenticated". 



Disconnect remote client 

Pre-condition "Accept Remote CUent Connection" has completed successfuUy. The client 
closes the socket or an unrecoverable error occurs or execution is 
terminated for the entire sj^tem. 
The client connection is closed. 

Close the socket connection and release any resotirces. 



Description 
Normal 
Execution Flow 
Post-condition 
Exceptions 



The client has been disconnected. 
None. 



Accept Service Provider Connection 

Pre-condition "Startup" has completed successfully. 



Description 
Normal 

Execution Flow 

Post-condition 

Exceptions 



A new client session is established. 
Establish a new session with the client 

A new client is connected to die Client Server Interfece. 
None. 



Register Service Provider 

Pre-condition "Accept Service Provider Connection" has completed correcdy. "Start 

Service" may be ongoing (0), but not necessarily. 
Description The Service Provider communicates tiie port number corresponding to die 

specified service name. 
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Noxmal 

Execution Flow 



Retrieve the service name and port number from the Service Provider. 

Verify that die executable file of the client (full path and file name) is the 
same as the exe in the services table for the specified service name (0). 

Store the port number in the services table. 

If one or more client requests are pending for this service, send tiie service 
port number to the clients as specified in 0 for all the pending requests^ 



Post-condition. 
Exceptions 



The port number has been added to the services table. 

The service name is not found in the table, ia this case return an error. This 
can happen if die service name has no registration file associated widi it (0). 

The service name already has a port number assigned to it. In this case 
override die port number with the new value and log ati error. This can 
happen when a named service is started, then it terminates, then it is started 
again and so fordi. 

Instead of communicating a port number, the Service Provider 
communicates a startup failure code. This is possible using the API 
specified in [2J. In diis case update die services table widi die failure code 
and set die port number to 0 (Invalid port number). 



Disconnect Service Provider 



Pre-condidon 

Description 

Normal 

Execution Flow 

Post-condidon 
Exceptions 



"Accept Service Provider Connection" has completed successfully. 
The client session terminates. 

Qose the client session and release any resources associated with it (except 
for the information stored in die services table). 

The client has been disconnected from the client server inter&ce. 
None 



Note however that a client may only have one pending request at a time. 
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CLAIMS 



1. A mediod of connecting a client running on a first computing device to a server 
running on a second computing device, comprising the steps of: 

(a) a service installed on the second computing device registering its 
published name, with a service broker on that device; 

(b) the client sending a message to the service broker specifying die name of 
the service; 

wherein the published name of die service conforms to a structured naming convention. 



2. The method of Claim 1 in which the stmctured nanding convention uses reversed 
domain infomiation. 

3. The method of Cla i m 1 in which die service broker uses a single well-known port 
number address. 



4. The method of Claim 1 in which the service obtains a connection point and 
informs die service broker of die connection point address and the service broker then 
informs die client of the connection point address. 

5. The method of Claim 4 in which the service broker informs the client of the 
connection point address and the client then uses tiiat address in communicating directiy 
with the server. 



6. The method of Claim 4 in which die connection point address is a port number. 

7. The mediod of Claim 4 in which, if a service is required more than once, the 
server providing the service will not be re-started, but instead the service broker uses 
cached address information. 
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8. The method of Claim 1 in which, -when services register -with the service broker, 
they register a version nvimber to indicate the version of the service that they are 
providing. 

9. The medaod of Claim 8 in which the client can request a specific version of a 
named service or it can omit die version, in which case die service broker will start die 
highest version available of die named service. 

10. The mediod of Claim 1 in which the service broker can serve external clients that 
are PC's or odier computers connected by a local link such as cable, Infca-Red or short 
distance radio (such as Bluetoodi) or by a remote link such as a network data connection. 

11. The mediod of Claim 1 in which die service broker provides audientication 
information such diat only audienticated external dients can access services. 

12. A computing device comprising (a) a server diat connects to a first computing 
device, and (b) a service broker to which a service installed on die computing device 
registers its published name and which receives a message firom die first computing 
device specifying diat name; wherein die published name of die service conforms to a 
structured naming convention. 

13. The device of Qaim 12 in which die service broker is programmed such liiat die 
structured ngming convention uses reversed domain information. 

14. The device of Claim 12 in which die service broker uses a single well-known port 
number address. 

15. The device of Claim 12 in which die service obtains a connection point and 
ipforms die service broker of die connection point address and die service broker dien 
informs the client of the connection point address. 
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16. The device of Claim 15 in which the service broker informs the client of the 
connection point address and the dient then uses that address in communicating direcdy 
wida die server. 

17. The device of Claim 15 in which the connection point address is a port nximber. 

18. ■ The device of Claim 15 in which, if a service is required more than once, the 
server providing the service will not be re-started, but instead the service broker uses 
cached address information. 

19. The device of Claim 12 in which, when services raster with the service broker, 
they register a version number to indicate the version of the service that diey are 
providing. 

20. The device of Claim 19 in which die client can request a specific version of a 
named service or it can omit die version, in which case the service broker will start the 
highest version available of die named service. 

21. The device of Claim 12 in which the service broker can serve external clients that 
are PC's or odier computers connected by a local link such as cable, In&a-Red or short 
distance radio (such as Bluetooth) or by a remote link such as a network data connection. 

22. The device of Claim 12 in which the service broker provides authentication 
information such that only authenticated external clients can access services. 
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